[rocky8_10] History Rebuild through kernel-4.18.0-553.158.1.el8_10 - #1554

jira KERNEL-1522
Rebuild_History Non-Buildable kernel-4.18.0-553.158.1.el8_10
commit-author Stefan Wiehler <stefan.wiehler@nokia.com>
commit 38f5024

With CONFIG_PROVE_RCU_LIST=y and by executing

  $ netcat -l --sctp &
  $ netcat --sctp localhost &
  $ ss --sctp

one can trigger the following Lockdep-RCU splat(s):

  WARNING: suspicious RCU usage
  6.18.0-rc1-00093-g7f864458e9a6 #5 Not tainted
  -----------------------------
  net/sctp/diag.c:76 RCU-list traversed in non-reader section!!

  other info that might help us debug this:

  rcu_scheduler_active = 2, debug_locks = 1
  2 locks held by ss/215:
   #0: ffff9c740828bec0 (nlk_cb_mutex-SOCK_DIAG){+.+.}-{4:4}, at: __netlink_dump_start+0x84/0x2b0
   #1: ffff9c7401d72cd0 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_sock_dump+0x38/0x200

  stack backtrace:
  CPU: 0 UID: 0 PID: 215 Comm: ss Not tainted 6.18.0-rc1-00093-g7f864458e9a6 #5 PREEMPT(voluntary)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
  Call Trace:
   <TASK>
   dump_stack_lvl+0x5d/0x90
   lockdep_rcu_suspicious.cold+0x4e/0xa3
   inet_sctp_diag_fill.isra.0+0x4b1/0x5d0
   sctp_sock_dump+0x131/0x200
   sctp_transport_traverse_process+0x170/0x1b0
   ? __pfx_sctp_sock_filter+0x10/0x10
   ? __pfx_sctp_sock_dump+0x10/0x10
   sctp_diag_dump+0x103/0x140
   __inet_diag_dump+0x70/0xb0
   netlink_dump+0x148/0x490
   __netlink_dump_start+0x1f3/0x2b0
   inet_diag_handler_cmd+0xcd/0x100
   ? __pfx_inet_diag_dump_start+0x10/0x10
   ? __pfx_inet_diag_dump+0x10/0x10
   ? __pfx_inet_diag_dump_done+0x10/0x10
   sock_diag_rcv_msg+0x18e/0x320
   ? __pfx_sock_diag_rcv_msg+0x10/0x10
   netlink_rcv_skb+0x4d/0x100
   netlink_unicast+0x1d7/0x2b0
   netlink_sendmsg+0x203/0x450
   ____sys_sendmsg+0x30c/0x340
   ___sys_sendmsg+0x94/0xf0
   __sys_sendmsg+0x83/0xf0
   do_syscall_64+0xbb/0x390
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
   ...
   </TASK>

Fixes: 8f840e4 ("sctp: add the sctp_diag.c file")
	Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
	Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
	Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/20251028161506.3294376-2-stefan.wiehler@nokia.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 38f5024)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1522
Rebuild_History Non-Buildable kernel-4.18.0-553.158.1.el8_10
commit-author Stefan Wiehler <stefan.wiehler@nokia.com>
commit 95aef86

For the following path not holding the sock lock,

  sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()

make sure not to exceed bounds in case the address list has grown
between buffer allocation (time-of-check) and write (time-of-use).

	Suggested-by: Kuniyuki Iwashima <kuniyu@google.com>
Fixes: 8f840e4 ("sctp: add the sctp_diag.c file")
	Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
	Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
	Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/20251028161506.3294376-3-stefan.wiehler@nokia.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 95aef86)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1522
Rebuild_History Non-Buildable kernel-4.18.0-553.158.1.el8_10
commit-author Stefan Wiehler <stefan.wiehler@nokia.com>
commit f1fc201

Move address list traversal in inet_assoc_attr_size() under the sock
lock to avoid holding the RCU read lock.

	Suggested-by: Xin Long <lucien.xin@gmail.com>
Fixes: 8f840e4 ("sctp: add the sctp_diag.c file")
	Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
	Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/20251028161506.3294376-4-stefan.wiehler@nokia.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit f1fc201)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

…out direction check

jira KERNEL-1522
cve CVE-2026-63913
Rebuild_History Non-Buildable kernel-4.18.0-553.158.1.el8_10
commit-author Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
commit bed6e04

An unintended behavior in the TCP conntrack state machine allows a
connection to be forced into the CLOSE state using an RST packet with an
invalid sequence number.

Specifically, after a SYN packet is observed, an RST with an invalid SEQ
can transition the conntrack entry to TCP_CONNTRACK_CLOSE, regardless of
whether the RST corresponds to the expected reply direction. The relevant
code path assumes the RST is a response to an outgoing SYN, but does not
validate packet direction or ensure that a matching SYN was actually sent
in the opposite direction.

As a result, a crafted packet sequence consisting of a SYN followed by an
invalid-sequence RST can prematurely terminate an active NAT entry. This
makes connection teardown easier than intended.

So, tighten the state transition logic to ensure that RST-triggered
CLOSE transitions only occur when the RST is a valid response to a
previously observed SYN in the correct direction.

	Cc: stable@vger.kernel.org
Fixes: 9fb9cbb ("[NETFILTER]: Add nf_conntrack subsystem.")
	Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
	Signed-off-by: Florian Westphal <fw@strlen.de>
(cherry picked from commit bed6e04)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1522
cve CVE-2026-63886
Rebuild_History Non-Buildable kernel-4.18.0-553.158.1.el8_10
commit-author Alexandru Hossu <hossu.alexandru@gmail.com>
commit 85db739

chap_server_compute_hash() allocates client_digest as
kzalloc(chap->digest_size) and then, for BASE64-encoded responses,
passes chap_r directly to chap_base64_decode() without checking whether
the input length could produce more than digest_size bytes of output.

chap_base64_decode() writes to the destination unconditionally as long
as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and
the "0b" prefix stripped by extract_param(), up to 127 base64 characters
can reach the decoder. 127 characters decode to 95 bytes. For SHA-256
(digest_size=32) this overflows client_digest by 63 bytes; for MD5
(digest_size=16) the overflow is 79 bytes.

The length check at line 344 fires after the write has already happened.

The HEX branch in the same switch statement already validates the length
up front. Apply the same approach to the BASE64 branch: strip trailing
base64 padding characters, then reject any input whose data length
exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder.

Stripping trailing '=' before the comparison handles both padded and
unpadded encodings. chap_base64_decode() already returns early on '=',
so the full original string is still passed to the decoder unchanged.

The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is
kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at
CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1
base64 characters reach the decoder. The maximum decoded size,
DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than
CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is
added at the call site to document this.

Fixes: 1e57338 ("scsi: target: iscsi: Support base64 in CHAP")
	Cc: stable@vger.kernel.org
	Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
	Reviewed-by: David Disseldorp <ddiss@suse.de>
Link: https://patch.msgid.link/20260521151121.808477-1-hossu.alexandru@gmail.com
	Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 85db739)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1522
cve CVE-2026-64191
Rebuild_History Non-Buildable kernel-4.18.0-553.158.1.el8_10
commit-author Weiming Shi <bestswngs@gmail.com>
commit 6036b50

The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]
as the transfer length. The existing check only clamps it to avoid
overrunning the chip->words[256] register array, but does not validate
it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union
i2c_smbus_data.block buffer (34 bytes total). The driver is a
development/test tool (CONFIG_I2C_STUB=m, not built by default)
that must be loaded with a chip_addr= parameter.

A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl
with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing
stub_xfer() to read or write past the end of the union
i2c_smbus_data.block buffer:

 BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)
 Read of size 1 at addr ffff88800abcfd92 by task exploit/81
 Call Trace:
  <TASK>
  stub_xfer (drivers/i2c/i2c-stub.c:223)
  __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)
  i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)
  i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)
  i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)
  __x64_sys_ioctl (fs/ioctl.c:583)
  do_syscall_64 (arch/x86/entry/syscall_64.c:94)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
  </TASK>

The bug exists because i2c-stub implements .smbus_xfer directly,
bypassing the I2C_SMBUS_BLOCK_MAX validation in
i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same
function correctly validates against I2C_SMBUS_BLOCK_MAX, but the
I2C_SMBUS_I2C_BLOCK_DATA case does not.

Fix by rejecting transfers with data->block[0] == 0 or
data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with
both the I2C_SMBUS_BLOCK_DATA case in the same function and the
I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().

Fixes: 4710317 ("i2c-stub: Implement I2C block support")
	Reported-by: Xiang Mei <xmei5@asu.edu>
	Signed-off-by: Weiming Shi <bestswngs@gmail.com>
	Reviewed-by: Jean Delvare <jdelvare@suse.de>
	Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
(cherry picked from commit 6036b50)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v4.18~1..kernel-mainline: 625874
Number of commits in rpm: 21
Number of commits matched with upstream: 7 (33.33%)
Number of commits in upstream but not in rpm: 625867
Number of commits NOT found in upstream: 14 (66.67%)

Rebuilding Kernel on Branch rocky8_10_rebuild_kernel-4.18.0-553.158.1.el8_10 for kernel-4.18.0-553.158.1.el8_10
Clean Cherry Picks: 7 (100.00%)
Empty Cherry Picks: 0 (0.00%)
_______________________________

Full Details Located here:
ciq/ciq_backports/kernel-4.18.0-553.158.1.el8_10/rebuild.details.txt

Includes:
* git commit header above
* Empty Commits with upstream SHA
* RPM ChangeLog Entries that could not be matched

Individual Empty Commit failures contained in the same containing directory.
The git message for empty commits will have the path for the failed commit.
File names are the first 8 characters of the upstream SHA